Day 7｜第一個模型上線：gpt-oss-120b 從模型庫到 API 的完整流程

2026 iThome 鐵人賽

DAY 7

AI Engineering

128GB 統一記憶體的三十天：DGX Spark 地端 LLM 與生成式 AI 部署實戰系列第 7 篇

18th鐵人賽

ivanusto

2026-08-20 23:49:17

229 瀏覽

分享至

為什麼是它 ? gpt-oss-120b 是可當基準用的量尺

開始動手前，先回答一個你可能想問的問題：都 2026 年 8 月了，為什麼第一個要上線用的模型是舊的 gpt-oss-120b，而不是上週剛釋出的 Qwen3.8-27B 或這兩天社群熱門的 Ornith 1.5？別擔心，這些之後都會教學和實作。

因為今天要示範的是流程，不是模型。gpt-oss-120b 是 DGX Spark 生態被研究得相當完整的模型，NVIDIA 官方的 Spark playbook 拿它當示範，llama.cpp、vLLM、Ollama、TensorRT-LLM 四條路對它全都有成熟支援與公開的參考數據。用它走第一次完整流程，每一步都有對照組可以驗證，萬一出問題時，可以確定是我自己的環境問題，而非模型支援問題。這正是拿來當基準用該有的特質，穩定、透明、人人可重複重現。

另一個理由是體積。120B 參數的 MoE 架構配上原生 MXFP4 量化約六十幾 GB，這種檔案大小在消費級顯卡上沒有單機單卡的解法只能多卡，但能舒服地躺進 Spark 的 128GB 統一記憶體。所以前面我在 Day 2 文章中試算過的記憶體數學呢，今天派上用場可以用實際行動驗證。

有一些 AI 模型的橫向測試比較，也會繼續用它當基準之一，模型端固定，量到的差異才能歸因於引擎。至於新模型們（Qwen3.8-27B、DeepSeek V4、Muse Glimmer、Ornith 1.5），會陸續登場擔任不同幕的主角，我們今天先把她們的舞台整理好。

事前檢查確認

依照我前幾天的準備，模型開跑前確認：

# 模型庫掛載正常
df -h /mnt/models

# GPU 就緒
nvidia-smi

# Docker 容器能吃到 GPU
docker run --rm --gpus all ubuntu nvidia-smi

三項都綠燈，我們就繼續往前走。

第一步：把權重放入模型庫

gpt-oss-120b 的權重在 Hugging Face 上，依 Day 5 的規矩下載到集中模型庫（在管理節點上執行）：

hf download openai/gpt-oss-120b \
  --local-dir /mnt/nas/AIModels/huggingface/gpt-oss-120b \
  --exclude "original/*" "metal/*"

--exclude 這兩個目錄不要省。openai/gpt-oss-120b 這個 repo 完整抓下來是 195.76 GB，但那不是一份 195 GB 的模型，而是同一份權重的三種封裝，HF safetensors 65.28 GB、原生 MXFP4 65.25 GB、Metal 65.24 GB。我們要給地端模型推論引擎吃的是 HF 格式那一份，另外兩份不加排除就會白白多下載 130 GB 喔。

下載完成後補一份 MANIFEST：

source: https://huggingface.co/openai/gpt-oss-120b
date: 2026-08-20
license: Apache-2.0
note: 系列基準模型，MXFP4 原生量化，AI 推論引擎橫項比較測試用量尺

實際占用空間用 du 確認：

du -sh /mnt/models/huggingface/gpt-oss-120b

60 GB，跟 index 標示的 65.2 GB 對得上（一個是 GiB 一個是 GB）。

第二步：用 llama.cpp 跑起來

第一次上線選 llama.cpp 路線，理由是它的回饋最直接，一個指令、一個行程、日誌全部攤在眼前，最適合首航。GGUF 版本的 gpt-oss-120b 同樣依 Day 5 的規矩先入庫（官方 MXFP4 的 GGUF 轉檔已有現成發布，也可以驗一下 sha256）。

這裡有個跟一般習慣不同的地方要提醒：官方發布的是單獨一個檔案，不是分片。gpt-oss-120b-MXFP4.gguf 就是完整的 63,387,346,208 bytes，沒有00001-of-00003 這種東西，等一下 -m 指過去就是指這一個檔。

llama.cpp 要自己編。GB10 的 compute capability 是 121，指定給 CMake 可以省掉一堆
用不到的架構：

cmake -B build -DGGML_CUDA=ON -DCMAKE_CUDA_ARCHITECTURES=121 \
      -DCMAKE_CUDA_COMPILER=/usr/local/cuda/bin/nvcc \
      -DCMAKE_BUILD_TYPE=Release
cmake --build build --config Release -j 16

啟動 llama-server：

llama-server \
  -m /mnt/models/gguf/gpt-oss-120b-mxfp4/gpt-oss-120b-mxfp4-00001-of-00003.gguf \
  --n-gpu-layers 999 \
  --ctx-size 32768 \
  --host 0.0.0.0 --port 8080

幾個設定值的說明。--n-gpu-layers 999 是模型的每一層都進入 GPU 的慣用寫法，統一記憶體架構下我們沒有理由分層。--ctx-size 先給 32K，上下文越大 KV cache 吃越多記憶體，第一次跑可以先保守以對。--host 0.0.0.0 這個設定是開放其他裝置連線過來，讓區網內其他電腦、筆電或 NAS 能打這個 IP 的 API，這是集中架構的重點，桌機和 PVE 上的服務之後都會來吃這個端點。

啟動過程中，可以留意日誌，看兩個時間點，一個是 AI 模型權重從 NFS 載入完成的時間，以及第一次推論就緒的時間。我的實測數字如下：

模型載入（NFS 路徑 10GbE）：169.6 秒
首次推論就緒：170.1 秒（服務開始監聽），第一個請求本身再花 2.5 秒回完

第三步：打通 API

服務起來後，先用最樸素的 curl 驗證 OpenAI 相容端點：

curl http://<Spark IP>:8080/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{
    "model": "gpt-oss-120b",
    "messages": [{"role": "user", "content": "用一句話介紹台灣的鐵人賽文化"}]
  }'

看到 JSON 回應裡吐出正常的繁體中文，這一刻就是地端 AI 的「Hello World」。接著從另一台機器（桌機 1）打同一個端點，驗證跨主機存取，順便確認 10GbE 網路上 API 呼叫的延遲感受。

接著從另一台機器打同一個端點，驗證跨主機存取，順便確認 10GbE 網路上 API 呼叫的延遲感受。同一個問題、同一個端點，從另一台機器打過來的解碼速度是 56.7 tokens/s，本機是 56.9。

生成速度的初步觀察（非正式跑分，之後我會教比較正式的方式）：

短提示詞生成速度：約 55 tokens/s（提示詞處理則是 157～169 tokens/s）
nvtop 觀察到的記憶體占用：61,397 MiB，約 60 GB

第四步：啟用一個真實客戶端

API 通了之後，掛一個日常工具驗證整條鏈路。任何支援自訂 OpenAI 端點的聊天介面都可以，把 base URL 指到 http://:8080/v1 即可。這一步的意義在於確認，模型庫在 NAS、推論在 Spark、使用介面在桌機，三個角色各司其職，Day 3 畫的那張架構圖，現在開始就是真實存在且活著了呢。

如果不知道要用哪一個用戶端來跑，那我推薦用 Open WebUI 這個工具，它支援大部分的推論模型，介面簡潔類似 ChatGPT、Gemini，不妨試試看。

第一次在 GB10 跑 LLM 的觀察筆記

第一次完整跑下來，幾個值得記錄的觀察。

載入時間比 Day 3 的估算慢了將近三倍，而且慢的地方不是網路。Day 3 我寫「10GbE 的實務有效吞吐約 1.1GB/s 出頭」，照這個算，63.39 GB 的權重應該58 秒載完。實測是 169.6 秒，2.9 倍。

NAS 的那張介面 ethtool 報 10000 Mb/s，網路本身是正確的。那我測試把整個 GGUF 用 sha256sum 從頭讀到尾，63.39 GB 花了 141 秒，換算 449 MB/s，只有 10GbE 理論值的四成。llama-server 的 169.6 秒換算是384 MB/s，跟這個上限吻合，也就是說 llama.cpp 沒有拖慢什麼，是儲存來源餵不滿 10GbE 網路。(雖然用 Vllm 跑會更快載入，但這是之後的是，我會再教學)

有趣的是，Day 3 的文章就有預告過說「NAS 的磁碟陣列可能比網路先到頂……TS-464 是4-bay 機種，如果裡面裝的是傳統硬碟組 RAID，循序讀取可能連 10GbE 都餵不飽。」當時寫的只是風險提醒，今天這篇實測就有驗證囉。

記憶體還有充裕餘裕

120B 模型加 32K 上下文之後，權重本體佔 60 GB，free -g 顯示 121 GB 裡還有53 GB available。這個餘裕之後可以拿來加大上下文、同時常駐第二款小模型，或是留給微調實驗。

生成速度的體感

我自己用起來，它的串流輸出感覺算順，與雲端 API 的落差感受呢，會覺得比雲端慢一點點是正常的，要想這是地端 AI 伺服器哪，小型機器，當然沒辦法和那些家大業大的雲端業者相比，但是跑在自己的設備上，資料不出境，也是你自己能掌控的資料用法，是不是很有意思呢。
前面 Day 2 文章中有說過 decode 其實受記憶體頻寬限制，實際速度體感如何，我會繼續實測給大家參考。

第一週的小記錄

架構奠基週到此完成。回顧這七天，定調與規劃（Day 1）、認識 GB10 與統一記憶體（Day 2）、網路與儲存拓撲（Day 3）、環境整備（Day 4）、模型庫治理（Day 5）、引擎選型框架（Day 6）、第一款選用的地端 AI 模型上線（Day 7）。從一台開箱的機器到一個能跨主機提供服務的地端 AI 環境，路已經打通，接下來要加速了。

不同模型的資料要移轉時可以從 NAS 移動到 GB10 上，反之亦然。